home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / tsql / doc / tsql.mail / 000058_kalua@cs.indiana.edu _Wed Mar 31 16:37:46 1993.msg < prev    next >
Text File  |  1996-01-31  |  1KB  |  34 lines
  1. Message-Id: <199303312137.AA15425@optima.cs.arizona.edu>
  2. Received: from moose.cs.indiana.edu by optima.cs.arizona.edu (5.65c/15) via SMTP
  3.     id AA15425; Wed, 31 Mar 1993 14:37:51 MST
  4. Received: by moose.cs.indiana.edu
  5.     (5.65c/9.4jsm) id AA14305; Wed, 31 Mar 1993 16:37:47 -0500
  6. From: "Patrick P Kalua" <kalua@cs.indiana.edu>
  7. Subject: Re: multi-valued attributes
  8. To: rts@cs.arizona.edu (Rick Snodgrass)
  9. Date: Wed, 31 Mar 1993 16:37:46 -0500 (EST)
  10. Cc: tsql@cs.arizona.edu
  11. In-Reply-To: <199303312122.AA11487@boojum.cs.arizona.edu> from "Rick Snodgrass" at Mar 31, 93 02:22:22 pm
  12. X-Mailer: ELM [version 2.4 PL21]
  13. Mime-Version: 1.0
  14. Content-Type: text/plain; charset=US-ASCII
  15. Content-Transfer-Encoding: 7bit
  16. Content-Length: 490       
  17.  
  18. > 
  19. > The proposed schema is much improved over previous ones, but now isn't
  20. > even in 3NF, which is somewhat embarrassing!  I suggest that we split
  21. > off the Skills attribute to a new relation:
  22. > 
  23. >         Skills (Name, Skill)
  24. > 
  25. > for which Skill would be a multi-valued attribute, in the
  26. > conventional, snapshot sense.  This change would, I think, result in
  27. > BNCF for all relations.
  28. > 
  29. > -- Rick
  30. > 
  31.  
  32.     It makes more sense. At least let us start with good design principles.
  33.  
  34. Patrick